1. Field of the Invention
The present invention relates to communications between software modules, and, more particularly, to a method and apparatus providing an extensible interface for inter-module communication.
2. Description of the Related Art
In today's technological economy, companies are moving towards managing and interacting with their customers through a wide variety of communication channels. Such communication channels include face-to-face interaction, telephone communications, facsimile (colloquially, “fax”) communications, e-mail, voice-mail, Internet information inquiries via “call me now and call me later,” collaborative sessions via the Internet and other such communications channels. With all these communication channels, companies are faced with efficiently managing each customer interaction while meeting desired service levels and maximizing customer satisfaction. In addition, companies are faced with optimally staffing and training their workforce to deal with these communication channels, whether through their call center(s), telebusiness organizations, or their sales, marketing, and service professionals.
Currently, many customers have dedicated e-mail inboxes, fax inboxes, and voice-mail boxes defined for specific business areas as well as automated call distributors. Employees are assigned to poll and manage the inquiries for each communication channel. Combined with the traditional call queues for inbound telephone calls, agents are tasked with managing all these communication channels while having no visibility into the queue status and priorities of each channel.
Thus, it is desirable to provide a system that includes a universal queue strategy capable of assigning, routing, and queuing work items from multiple channels of communications to an agent having the appropriate skills to respond to the request. This reduces the response times and customer satisfaction, while balancing priorities amongst multiple communication channels.
As will be appreciated by those of skill in the art, the queuing of such work items may be performed by a software module dedicated to such tasks. Such a module would dole out work items to agents as appropriate, based on some paradigm. In providing such functionality in a separate module, the question of the manner in which such a module (and indeed, any such inter-module communications) are to take place.
A traditional approach would be to define a application programming interface (API) that would allow calls to be made to the queuing module, in order to produce the desired results (e.g., the queuing of a work item). Alternatively, a dynamic link library (DLL) could be employed. A DLL is a collection of sub-modules (e.g., subroutines or objects/methods), any of which can be called (instantiated) when needed by a program currently being executed in a computer. DLL files are so named because they are dynamically linked with the program that uses them during program execution rather than being compiler with the main program. Again, as with a library, an API is provided to allow the programmer to access the functions contained therein.
Unfortunately, by using a library or DLL, several obstacles can present themselves. First, the library or DLL may have what are termed “side effects”—that is, one or more of the sub-modules may cause unexpected changes in the data of the calling module. Moreover, if the calling module supplies data to the sub-module in the wrong format, the sub-module may simply take the incorrectly formatted data as data in the expected format, again producing unexpected results. Given there and other sources of errors, the time required to test and debug software thus created is increased substantially, as such effects are difficult to track down. Collaboration of different groups creating various modules is also affected, as the time required to integrate the module with the library/DLL is also increased. In fact, not only is the creation of software using such techniques error prone, but the maintenance of such systems also becomes more difficult, with the potential for small changes to the module and/or sub-modules to have catastrophic unforeseen effects. Thus, a way for modules to communicate that avoids the aforementioned problems is desirable, as such a technique would provide the requisite functionality without the potential burdens of increased development time, integration time and maintenance efforts.